REMARKS 

Presently pending in the current application are claims 1-52. 
35 USC 112 Rejections 

Claim 1 was rejected based on 35 USC 1 12. As will be shown below, Applicant 
believes that the subject matter previously provided in claim 1 was described in the 
specification. As such, Applicant respectfully requests the 35 USC 112 rejection be 
removed. 

35 USC 102(e) Rejections 

Claim 1 was rejected as being anticipated by Bakshi et al. (US 6,772,200). 
Although Applicant does not believe that Bakshi fully teaches or suggests original claim 
1, as previously described, Claim 1 was amended to include the limitations of: 

if a message for the user is desired: 

sending, by the consolidating and management device, new policy 

information to the directing device along with a unique identifier for that policy; 

and 

examining, by the redirecting device, the accessed user upstream traffic to 
determine if a redirection will be sent, wherein the examining occurs without 
modifying the accessed user upstream traffic; 

Support for these limitations, which are not taught or suggested by Bakshi, can be 
found at least in paragraphs [0111] and [0112] of the instant application: 

[0111] Implementation Approach: Whenever a redirecting device receives a TCP 
SYN packet, it looks in its table to find the IP address of the source. If the address is not 
in the table, or is expired, it sends a request to the address management device, along 
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with a unique identifier for any policy that it has cached for that IP address (in the case of 
an expired entry). Depending on configuration, it could then forward the original packet 
back to the router, or discard or delay the packet. If the address is unknown, it also 
creates an entry for the IP address with a short expiration, so that it will not query the 
consolidating and management device again for a little while. 

[0112] The address management device then queries the address management 
database (e.g., DHCP) to obtain the Cable Modem address associated with that IP 
address, and may also obtain the DHCP lease expiration time. Once the consolidating and 
management device determines the user associated with the IP address, if a message for 
that user is desired, then it can send new policy information to the directing device along 
with a unique identifier for that policy. If the unique policy identifier sent by the 
redirecting device indicates that the redirecting device already has the correct policy 
information available, then the consolidating and management device does not need to re- 
send it; it can just re-activate it. In addition, the DHCP lease expiration time is sent, even 
if no message is desired. The redirecting device updates its table so that it will not query 
the consolidating and management device again concerning that IP address until the 
DHCP lease expires, or more likely, some fraction of that time, perhaps with a 
limit. Based on the aforementioned remarks and amendments, Applicant believes the 
present invention is in condition for allowance. A Notice of Allowance is therefore 
respectfully requested. 
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Previously Presented Claim 1 

Claim 1 was previously amended to include, among other limitations: 
Communicating real-time to users of an ISP, comprising: 

Accessing by a redirecting device only user upstream traffic from a destination 
site requested by the user; 

Identifying the user by using data available from the user and provider 
infrastructure to provide a fixed identifier based on the accessed user upstream traffic ; 

Providing, by the redirecting device, the fixed identifier to a consolidating and 
management device, wherein the consolidating and management device is separate 
from the redirecting device; 

If a message for the user is desired, examining, by the redirecting device, the 
accessed user upstream traffic to determine if it is possible to send a redirection, wherein 
the examining occurs without modifying the accessed user upstream traffic; and 

Selectively redirecting the message to the user for display on a message vehicle. 

The Examiner rejected claim 1 by equating "accessing only user upstream traffic" 
as it appears in claim 1 to Bakshi's proxy. As is known, a proxy handles two-way traffic 
(i.e. upstream and downstream traffic). For example, Bakshi states (bolded for 
emphasis), "In the arrangement shown in FIG. 5, transcoding server 34 includes an HTTP 
(HyperText Transfer Protocol) remote proxy 36, capable of accessing network 18 over 
server/network communications link 16. HTTP remote proxy 36 provides functionality 
different from known network proxies, which generally are little more than a conduit for 
requests to, and replies from, external Internet resources, in that it is capable not only of 
examining such requests and replies, but also of acting upon commands in the requests 
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by, for example, determining whether or not to transcode content. Moreover, using 
transcoder 20, HTTP remote proxy 36 is capable of changing content received from 
network 18 prior to returning it to a requesting network client 12. 

Conversely, previously presented claim 1 advantageously discloses accessing 
only user upstream traffic, providing a fixed identifier based on the accessed user 
upstream traffic, examining the accessed user upstream traffic without modifying the 
accessed user upstream traffic. 

Conclusion 

Applicant believes amended claim 1 is not taught or suggested by Bakshi and thus 
is in condition for allowance. As such, Applicant respectfully request claim 1 as well as 
all claims that depend from claim 1 to be passed to allowance. 

If the Examiner has any other matters which pertain to this Application, the 
Examiner is encouraged to contact the undersigned to resolve these matters by 
Examiner's Amendment where possible. 

Respectfully Submitted, 

By: /Raffi Gostanian/ 

Raffi Gostanian, Jr. 
Registered Patent Agent 
Reg. No. 42,595 

Date: 02/08/2010 

RG & Associates 

1103 Twin Creeks, Ste. 120 

Allen, TX 75013 
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